Während das Zusammenspiel von Development und Operations dank wachsender Erfahrungswerte immer runder läuft, meldet sich eine weitere wichtige IT-Disziplin zu Wort: Mitarbeiter, die für die Sicherheit einer Infrastruktur verantwortlich sind, wollen ebenfalls stärker in die holistische Betrachtung von technologischen Ökosystemen eingebunden werden. Mit DevSecOps setzt sich eine Denk- und Arbeitsweise durch, bei der die Sicherheit von IT-Infrastrukturen vom ersten Tag an über den gesamten Softwarelebenszyklus hinweg mitgedacht wird. Grundlegende Voraussetzung für ein wirkungsvolles Ineinandergreifen aller drei Disziplinen ist ein einheitlicher Blick auf zentrale Kennzahlen und alle sicherheitsrelevanten Signale.
Bei DevSecOps handelt es sich letztlich um die logische Weiterführung des DevOps-Gedankens: Unternehmen und IT-Teams, die die Vorteile einer engen Zusammenarbeit zwischen Entwicklung und Betrieb ausschöpfen wollen, dürfen das Thema Security nicht isoliert betrachten. Trotzdem ist es in den meisten Organisationen noch heute so, dass die Sicherheit einem speziell für diese Aufgabe eingerichteten Team zugewiesen wird. In Zeiten agiler und oft sehr schneller Softwareentwicklungen stellt die nachgelagerte Betrachtung von Security allerdings ein nicht unerhebliches Problem dar. Überholte Sicherheitsmethoden sind oft sehr statisch und reaktiv und können damit selbst die besten Entwicklungs- und Anwendungsprozesse ausbremsen.
Flexibilität schafft komplexe Strukturen
So wie Cloud Computing inzwischen vielerorts ein integraler Bestandteil moderner Architekturen geworden ist, entwickeln sich offene, API-basierte Ansätze ebenso zu einem grundlegenden Bestandteil zukunftsfähiger IT-Infrastrukturen. Je komplexer unsere technologischen Ökosysteme werden, umso wichtiger wird es sein, nahtlose, voll integrierte Prozesse und Lösungen sicherzustellen – eine Maxime, die zunehmend auch für Sicherheitsmaßnahmen gilt. Bei DevSecOps geht es deshalb um mehr als nur darum, ein Notebook, ein einzelnes Server-Rack oder irgendeinen spezifischen Log-in abzusichern. DevSecOps zielt auf den Schutz kompletter Infrastrukturen – insbesondere dann, wenn sie sich auf dem Weg in die Cloud befinden. So liegt der zentrale Vorteil Cloud-basierter Migrationsvorhaben zwar in der neu gewonnenen Flexibilität; ihre Achillesferse ist allerdings die Komplexität, die hieraus entsteht. Die vielschichtige Natur und damit verbundene steigende Komplexität moderner IT-Architekturen macht verwundbar und stellt eine regelrechte Einladung für Hacker und externe Angreifer dar. Deshalb müssen Cloud-Infrastrukturen, die den Prinzipen des DevOps folgen, auch in Fragen der Systemsecurity überdacht und holistisch betrachtet werden. DevSecOps liefert einen ausgesprochen vielversprechenden Lösungsansatz, um die Anforderungen einer ganzheitlichen Verankerung von Sicherheitspraktiken zu realisieren.
Hindernisse durch offene Kommunikation abbauen
Unternehmen, die ihre IT-sicherheitsrelevanten Prozesse modernisieren und übergreifende DevSecOps-Strukturen etablieren wollen, werden sich zunächst mit ausgesprochen menschlichen Hürden konfrontiert sehen. Sie sind in erster Linie kommunikativer Natur und können durch einen offenen Dialog und die Bereitschaft, voneinander zu lernen, sehr gut gelöst werden. Eine dieser Herausforderungen liegt im Development: Entwickler überführen Hunderte Male am Tag einzelne Softwaresequenzen in den operativen Zustand. Bei dieser Menge an Code hat das Securityteam keine Chance, jede einzelne Zeile zu überprüfen. Deshalb ist es so wichtig, dass die Entwickler selbst für sicherheitsrelevante Aspekte sensibilisiert werden und ihnen entsprechende Tools vom Securityteam für statische und dynamische Analysen zur Verfügung gestellt werden. Idealerweise sind sie in der Lage, potenzielle Schwachstellen und Angriffspunkte bereits in dem Moment zu erkennen, in dem sie produziert werden – und diese Erkenntnisse in einem offenen und lösungsorientierten Dialog mit den Kollegen vom gesamten DevSecOps-Team zu teilen, um den gewünschten Wissenstransfer zu erreichen.
Auf der anderen Seite dieser Medaille steht das Securityteam: IT-Sicherheitsverantwortliche sind traditionell darauf bedacht, ihre Tools in das Gesamtdesign ebenso wie in einzelne Anwendungen und Services einzubinden. Sie verfügen allerdings oft nicht über die gleiche Expertise wie ihre Kollegen aus der Entwicklungsabteilung, wenn es um die Zuverlässigkeit und die Performance von Lösungen geht. Deshalb ist es sehr wichtig, dass Securityteams auch diese wichtigen Aspekte berücksichtigen und bereit sind, von der Erfahrung ihrer Kollegen aus dem Development-Bereich zu profitieren. Das bedeutet unter anderem, relevante Daten und Systemeinblicke zu teilen und für die Anwendungen und Tools der DevOps-Spezialisten bereitzustellen. Diese Daten müssen auch zur Analyse von Securitylösungen genutzt werden: Es muss ganz klar sein, inwiefern eine sicherheitsrelevante Software das Gesamtsystem tangiert, bevor das Tool tatsächlich zum Einsatz kommt.
Vor- und Nachteile von Securitytools abwägen
Es ist vielleicht kein revolutionärer Paradigmenwechsel – und dennoch werden Unternehmen eine spürbar bessere Systemsicherheit realisieren können, wenn sie ihre Securityimplementierungen integrierter anordnen, als es vielerorts bisher der Fall war. Das betrifft alle Prozesse und Handhabungen im Lebenszyklus eines Softwareproduktes, die zur Vermeidung von Attacken, Betrug und allen anderen externen Bedrohungen relevant sind. Durch die Realisierung von DevSecOps sind Sicherheitsmaßnahmen nicht länger an das Ende eines Lifecycles verbannt. Stattdessen wird das Securityteam Mitglied bei der Entwicklung und dem Anwendungsbetrieb.
Eine besondere technologische Herausforderung für die IT-Security besteht in vielen Unternehmen darin, dass ihre Werkzeuge meist nur eingeschränkt automatisiert, bestenfalls teilautomatisiert arbeiten und damit oft nur schwer in moderne Systemwelten integriert werden können. Diese Problematik wird durch den Umstand verschärft, dass zahlreiche Sicherheitstools lange brauchen, bis sie tatsächlich operativ sind – und damit nicht in das Tempo, das Design und die Entwicklungsprozesse des gesamten technologischen Ökosystems passen. Deshalb empfiehlt es sich an dieser Stelle ganz genau hinzuschauen, inwiefern die betreffenden Sicherheitspraktiken überhaupt einen Mehrwert liefern. Je nach Ausgang einer derartigen Effizienzanalyse kann entschieden werden, ob ein Weg zur Integration von Tools mit geringerer Entwicklungsgeschwindigkeit gefunden werden sollte oder ob die Nachteile verlangsamter Development-Workflows den Nutzen übertreffen und deshalb besser auf die eine oder andere Sicherheitslösung verzichtet werden sollte. Hinzu kommt der Umstand, dass Sicherheitstools eine große Anzahl an False-Positive-Meldungen produzieren. Für alle Lösungen, deren Einsatz als sinnvoll erachtet wurde, ist es deshalb zielführend, sie mit einer möglichst hohen Spezifität zu konfigurieren und, um ein fortlaufendes Nachjustieren zu vermeiden, schon zu Beginn auf möglichst exakt arbeitende Systeme zu setzen.
IT-Security integrieren, Redundanz vermeiden bzw. gezielt managen
Sicherheitsstrategien und die entsprechenden Lösungen müssen an die Live-Systeme angepasst sein. IT-Teams sollten das Entstehen von Securitysilos vermeiden, da diese nicht mit der operativen Umgebung integriert werden können, sondern eine Parallelwelt darstellen. Die Gründe hierfür liegen unter anderem darin, dass verteilte Securitysysteme meist redundante Datensätze und Dubletten mit sich bringen. Das ist spätestens dann der Fall, wenn Informationen aus unterschiedlichen isoliert vorgehaltenen Lösungen zusammengeführt werden sollen. Sind die Daten nicht bereinigt, harmonisiert und dadurch konsistent, können keine zuverlässigen Aussagen über sicherheitsrelevante Zustände und Ereignisse getroffen werden. Doch das ist nicht die einzige Nebenwirkung von Dateiredundanzen: Liegen Daten doppelt vor, so müssen diese auch doppelt verwaltet werden – ein Faktor, der für unnötige Kosten sorgt.
Geradezu gegensätzlich, aber ebenso einflussreich ist das Phänomen fehlender oder lückenhafter Datenbestände. Oft ist es so, dass einem System Informationen vorliegen, die dem anderen wiederum gänzlich fehlen. Hier ist ein Abgleich ebenfalls unumgänglich, um bei Zusammenführung von sicherheitsrelevanten Informationen aus unterschiedlichen Systemen eindeutige Aussagen treffen zu können. Ob Dubletten oder blinde Flecken in den Datensätzen, beides ist sowohl aus operativer Sicht als auch für ein übergreifendes Securitymonitoring problematisch. Schließlich kann ein Securityteam nur davon profitieren, wenn es Zugriff auf Daten bekommt, die vorab aufgrund isolierter Workflows und Datenzugriffe nicht eingesehen werden konnten. In den meisten Fällen handelt es sich um operative Daten, die für Sicherheitsverantwortliche extrem nützlich sein können – egal, ob es sich um die Logeinträge laufender Development-Prozesse oder um Performancekennzahlen aktiver Maschinen handelt. Um die Entwicklung, den Betrieb und die Sicherheit von IT-Infrastrukturen nachhaltig besser miteinander zu verzahnen, müssen alle Mitarbeiter einen einheitlichen Blick auf relevante Daten und Analysen haben – und das eben nicht nur im Hinblick auf die Performance, sondern auch in Fragen der Systemsicherheit. Nur so können sich Unternehmen darauf verlassen, dass die Kollegen im interdisziplinären DevSecOps-Team von den gleichen Dingen reden, wenn sie Bedrohungen und ein präventives Risikomanagement thematisieren.
Hintergrundrauschen beachten
Während die IT-Komplexität größer wird, werden zugleich die jedem technologischen System eigenen „Hintergrundgeräusche“ lauter. In modernen Infrastrukturen kann uns dieses Grundsummen eine Menge darüber verraten, was gerade in unseren Netzwerken vor sich geht – wenn wir in der Lage sind, die Signale richtig zu deuten. So sind in den Logs (den Protokolldateien von Anwendungen, Netzwerkmodulen und sonstiger protokollbasierter Software) riesige Menge an Messdaten und Signalen gespeichert, die nur auf intelligente Art und Weise ausgelesen werden wollen, um wertvolle Informationen über kritische Sicherheitsrisiken zu liefern. Ein anschauliches Beispiel ist die Identifizierung von ungewöhnlichen, aber systematisch wiederkehrenden Zugriffsversuchen. Da auch die Komplexität und Möglichkeiten für Angriffe steigen, können diese auch von unterschiedlichen IP-Adressen von einem Angreifer kommen. Das könnte ein Indikator dafür sein, dass gerade ein externer Angreifer versucht, sich unautorisierten Zugang zu einer Infrastruktur zu verschaffen.
Je größer ein Unternehmen und je vielschichtiger seine IT-Infrastruktur, umso höher ist natürlich auch das Aufkommen von Logeinträgen. Doch bereits bei kleineren Mittelständlern entstehen täglich mehrere Gigabyte an securityrelevanten Protokolleinträgen. Wichtig ist, dass jeder Anfrage eine eindeutige ID zugeordnet wird. Eine derartige Tracing-ID kann dann über sämtliche Schnittstellen zwischen Quellen und Diensten hinweg weitergegeben werden. Auf diese Weise sind Unternehmen in der Lage, jeden beliebigen Netzwerkteilnehmer, jeden Logeintrag, jede Anfrage und jeden aktiv beteiligten Service konkret miteinander in Verbindung zu bringen.
Standards für einheitliche Namensgebung
Die Zusammenführung von Logs aus einer Vielzahl unterschiedlicher Systeme und Anwendungen führt in der Regel zu einer wilden Anhäufung von Daten, die allein schon aufgrund der Attributbezeichnungen zu massenhaften Dubletten führen kann. Als Beispiel sei eine Client-IP angeführt, die als clientIP, client_IP_address, remote_adress oder auch client.ip im System hinterlegt sein kann. Ist die Namensgebung nicht harmonisiert, kann dies zwischen Development, Operation und Security für spürbare Verwirrung sorgen. Im Sinne einer vereinheitlichten, zentralen Vorhaltung von Logdateien ist es deshalb hilfreich, Standardattribute zu definieren und Aliasing-Mechanismen anzuwenden. So ist gewährleistet, dass IT-Mitarbeiter über alle Disziplinen hinweg die gleiche Sprache sprechen.
Es empfiehlt sich außerdem, alle Felder innerhalb einer Logdatei zu dokumentieren, die untereinander in Beziehung stehen könnten. Das kann beispielsweise eine IP-Adressen sein, die im Zusammenhang mit definierten Standardattributen betrachtet werden kann. Zur Veranschaulichung: Angenommen, die IP 1.2.3.4 interagiert mit einem System. Der Betreiber der Infrastruktur kann anhand einer konsistenten Dokumentation alle Logs in Verbindung mit dieser spezifischen IP-Adresse hin untersuchen. Dadurch wird sichtbar, welche der beteiligten Komponenten mit der IP 1.2.3.4 interagiert hat. Das Gleiche ist für zahlreiche andere Attribute, wie etwa einen Benutzernamen oder auch eine E-Mail-Adresse, möglich.
Securitysignale für akute Bedrohungen
Neben Logdateien, die eine systematische Analyse und auch Prognose sicherheitsrelevanter Kennzahlen erlauben, gibt es Securitysignale, die aktiv werden, sobald eine Bedrohung entdeckt wurde. Die Identifizierung von Bedrohungen, wie etwa einer feindlichen Accountübernahme, basiert auf sogenannten Detection Rules, einem Regelwerk, in dem logische Regeln zur Erfassung von spezifischen Securityereignissen hinterlegt sind. Schließlich repräsentiert ein einzelner Logeintrag lediglich ein isoliertes Ereignis, wohingegen zahlreiche Einträge von verschiedenen Quellen und Netzwerkteilnehmern eine komplette Ereigniskette, also eine Geschichte erzählen. Deshalb werden in Umgebungen, in denen nach dem DevSecOps-Prinzip gearbeitet wird, sowohl Processing-Signale als auch Anwendungsdaten zusammengeführt, mit Metadaten angereichert und nach festgelegten Regeln analysiert. Da Securitysignale grundsätzlich komplex sind, bedarf es eines klar definierten Frameworks, um die Sicherheit in vielschichtigen Infrastrukturen zu gewährleisten und Bedrohungen proaktiv entgegenzutreten. Metadaten, die Aussagen über den Ursprung eines Signals und seine Bewegungsmuster zulassen, leisten eine wichtige Hilfestellung, wenn es darum geht, Regelmäßigkeiten zu erkennen und damit einen guten Rundumblick über Architekturen und ihre sicherheitsrelevanten Schwachstellen zu erhalten. Das Ergebnis sind zuverlässige und stets zeitnahe Entscheidungen in den DevSecOps-Teams.
Dashboard sorgt für einheitlichen Blick aufs Ganze
Für Teams, die disziplinübergreifend das DevSecOps-Prinzip umsetzen wollen, ist es wichtig, dass alle Beteiligten die Zusammenführung und Auswertung von Signalen einsehen können. Ein einheitliches und unkompliziert konfigurierbares Dashboard ist deshalb eine unverzichtbare Voraussetzung, wenn DevSecOps wirklich funktionieren soll. Ein Beispiel: Entdeckt die Securitymonitoringlösung eine sogenannte Credential-Stuffing-Attacke, also den Versuch, einen Log-in durch automatisierte Passworteingabe zu knacken, kann der verantwortliche Mitarbeiter per Knopfdruck die Darstellung im Log-Explorer aktivieren. Er gewinnt konkrete Einblicke in alle Logs, die das Security-Signal getriggert haben. Die Regelwerke, die diesen Prozessen zugrunde liegen, können allesamt in der Benutzeroberfläche konfiguriert werden. Es besteht die Möglichkeit, vordefinierte Regeln zu nutzen oder auch komplett neue zu entwerfen. Über ein REST API können die Detection Rules sogar auf Codeebene verwaltet werden.
Ein übergreifendes DevSecOps-Monitoring schafft die nötigen Voraussetzungen, schnell und effizient auf Gefährdungen der Systemsicherheit zu reagieren und interdisziplinär nachhaltige Mechanismen für spezifische Securityherausforderungen zu entwickeln. Wenn DevOps und Security ihre Datenpools nicht separat vorhalten, sondern diese wichtige Ressource zentral zusammenführen und harmonisieren, eröffnen sich damit unterschiedliche Perspektiven auf die sicherheitsrelevanten Faktoren einer spezifischen Infrastruktur – und die Chance, mit DevSecOps lückenlose Sicherheit über den gesamten Lebenszyklus eines Systems hinweg zu realisieren.
